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RELATED APPEALS AND INTERFERENCES 
There are no known related appeals or interferences. 

5 STATUS OF CLAIMS 

Claims 1 through 12 are pending in the above-identified patent application. Claims 1, 
4, 7, and 10 remain rejected under 35 U.S.C. § 102(e) as being anticipated by Cruickshank et al. 
(United States Patent Number 6,389,005) and claims 2, 5, 8, and 1 1 remain rejected under 35 U.S.C. 
§ 1 03(a) as being xmpatentable over Cruickshank et al., and further in view of Adelman et al. (United 
1 0 States Patent Number 6,006,259). The Examiner has indicated that claims 3, 6, 9, and 12 would be 
allowable if rewritten in independent form including all of the limitations of the base claims and any 
intervening claims. 

STATUS OF AMENDMENTS 
1 5 There have been no amendments filed subsequent to the final rejection. 

SUMMARY OF INVENTION 
The present invention is directed to a method and apparatus for congestion 
management in a multi-branch Internet Protocol (IP)-based private branch exchange (PBX) switch. 

20 The multi-branch IP-based PBX switch is interconnected through (i) a packet network referred to as 
the primary network, such as a wide area network (WAN), and (ii) an alternate network, such as the 
public switched telephone network (PSTN). (Page 3, line 28, to page 4, line 11). Packet phone 
adapters (PP As) associated with each packet telephone unit monitor packet telephone calls and report 
delay information to communication servers. The conmumication server can reroute the packet 

25 telephony calls through the secondary network upon detection of congestion in the underlying 
primary network, thereby preserving voice quality. (Page 4, lines 12-25.) 

ISSUES PRESENTED FOR REVIEW 
i. Whether claims 1, 4, 7, and 10 are properly rejected under 35 U.S.C. §102(e) as 
30 being anticipated by Cruickshank et al.; and 
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ii. Whether claims 2, 5, 8, and 11 are properly rejected xinder 35 U.S.C. 
§ 103(a) as being unpatentable over Cruickshank et al., and further in view of Adehnan et al. 

GROUPING OF CLAIMS 
5 The rejected claims stand and fall together. 

ARGUMENT 

Independent claims 1, 4, 7, and 10 are rejected under 35 U.S.C. § 102(e) as 

being anticipated by Cruickshank et al. 

Regarding claims 1 , 4, and 1 0, the Examiner asserts that Cruickshank teaches 

"a congestion indicator status associated with each path in said primary n etwork, said 

congestion indicator status indicating whether said path is congested and based on congestion 

data from at least one device that participated in a packet telephony communication." 

Applicants note that Cruickshank teaches that a Quality of Service parameter 

should be used to determine the network on which a call should be routed. In particular, 

Cruickshank teaches: 

whenever a call is established over the internet, PBX 14 monitors the 
quality of service (QoS) of the internet call path (block 134). This involves 
measuring s uch p arameters as/? acket d elay, then umber of data packets 
dropped and throughput. Preferably QoS is measured using the known Real- 
Time Transport Control Protocol (RTCP). 

Col. 2, lines 32-36. 

Thus, Cruickshank monitors QoS parameters such as packet delay, packets dropped and 
25 throughput. Cruickshank does not address the monitoring of congestion. 

Applicants note that there is a significant difference between the monitoring 
of the QoS parameters taught by Cruickshank and the monitoring of congestion, as required 
by the present invention. The QoS parameters cited by Cruickshank do not accurately predict 
congestion and vice versa. 
30 For example, the QoS parameters cited by Cruickshank can falsely determine 

that there is congestion within a path of a network when, in fact, congestion does not exist. 
Consider the case where a "packets dropped" parameter drops below a minimum quality of 
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service threshold. In some cases, this could be the result of buffer overflow at an outgoing 
network link due to congestion. In other cases, dropped packets could be the result of 
corrupted packet headers due to bit errors occurring in the network (especially in wireless 
networks) or the result of an overloaded receiver, even though congestion was not present in 
5 the network. Thus, when the "packets dropped" parameter drops below a minimum 
threshold, it is not necessarily an indicator of congestion. 

Similarly, while a long packet delay parameter can be indicative of congestion 
if it is the result of relatively full buffers on outgoing network links, it could also be the result 
of delays in sending the packet to the network from the packet's source, or could result from 

10 complex packet processing tasks required at intermediate network nodes, such as firewalls, 
even though congestion was not present in the network. Thus, packet delay is not necessarily 
an indicator of congestion. 

Similarly, the use of the QoS parameters cited by Cruickshank can falsely 
determine that there is no congestion within a path of a network when, in fact, congestion 

1 5 does exist. For example, upon a network congestion condition, packets will be dropped in 
the short term and there will be a temporary improvement in the QoS parameters. Such 
improved QoS parameters, however, are not indicative of no congestion, but rather, merely 
reflect the fact that packets were dropped and there was a temporary improvement in network 
conditions. The effect of dropping packets could result in a shorter packet delay for the 

20 packets that remain in the network, a condition typically associated with no congestion. 
Thus, the shorter packet delay could falsely indicate that congestion does not exist when, in 
fact, there is network congestion. 

In the Advisory Action, the Examiner maintains the assertion that the 
measiu-ement of throughput can be a measurement of congestion and notes that "Cruickshank 

25 teaches that the delays are assumed due to congestion (col. 2 lines 46-49)." This teaching by 
Cruickshank, however, actually supports the argument that the monitoring of the QoS 
parameters taught by Cruickshank and the monitoring of congestion are not the same. 

Cruickshank teaches that, if the QoS on the Internet is not high enough, the 
PSTN is utilized to transport the call. Cruickshank then teaches (in the text cited by the 

30 Examiner: col. 2, lines 46-49) that a confirmation tone is sent over the "PSTN instead of the 
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internet because the internet is assumed to be suffering delays due to congestion at this 
time." (Emphasis added.) Thus, Cruickshank is admitting that the QoS measurement of the 
internet that indicated the PSTN should be utilized is only assumed to be an indication of 
congestion. It cannot, however, be defined as an indicator of congestion. 
5 Independent claim 1 requires "a congestion indicator status associated with 

each path in said primary network, said congestion indicator status indicating whether said 
path is congested;" independent claims 4 and 10 require setting "a congestion indicator flag 
associated with said path if said congestion data indicates that a path associated with said 
packet telephony communication is congested;" and independent claim 7 requires "reporting 

10 said congestion data to a centralized server that performs overload control, whereby said 
centralized server evaluates said congestion data to determine if a path associated with said 
packet telephony conmiunication is congested." 

Thus, Cruickshank does not disclose or suggest a "congestion indicator" or 
"congestion data," as required by independent claims 1, 4, 7, and 10. 

15 Conclusion 

The rejections of the independent claims xmder sections §102 and §103 in 
view of Cruickshank et al. and Adeknan et al, alone or in any combination, are therefore 
believed to be improper and should be withdrawn. The remaining rejected dependent claims 
are believed allowable for at least the reasons identified above with respect to the 

20 independent claims. 

The attention of the Examiner and the Appeal Board to this matter is 

appreciated. 

RespectfiiUy, 

Date: May 14, 2004 Kevin M.Mason 

Attorney for Applicant(s) 
Reg. No. 36,597 

30 Ryan, Mason & Lewis, LLP 

1300 Post Road, Suite 205 
Fairfield, CT 06824 
(203) 255-6560 
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APPENDIX 

1 . An overload control method for use in a multi-branch Internet Protocol-based private 

branch exchange system within a network environment having a primary network and at least one 
5 alternate network, said method comprising the steps of: 

maintaining a congestion indicator status associated with each path in said primary 
network, said congestion indicator status indicating whether said path is congested and based on 
congestion data from at least one device that participated in a packet telephony communication; 

receiving a call set up request from a source terminal; 
1 0 determining if a primary path between said source terminal and a destination terminal is 

congested using said congestion indicator status; and 

routing said call using said at least one altemate network if said primary path between 
said source terminal and a destination terminal is congested. 

15 2. The method of claim 1 , further comprising the step of setting a timer that will cause said 

congestion indicator flag to automatically expire after a predefined period of time. 

3. The method of claim 2, wherein said timer expires after a period of time within which 
said congestion should have been alleviated. 

20 

4. A congestion management method for use in an Internet Protocol-based private branch 
exchange system within a packet network environment, said method comprising the steps of: 

receiving congestion data from at least one device that participated in a packet telephony 
communication; 

25 determining if said congestion data indicates that a path associated with said packet 

telephony communication is congested; and 

setting a congestion indicator flag associated with said path if said congestion data 
indicates that a path associated with said packet telephony communication is congested. 

30 
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5 . The method of claim 4, further comprising the step of setting a timer that will cause said 
congestion indicator flag to automatically expire after a predefined period of time. 

6. The method of claim 5, wherein said timer expires after a period of time within which 
5 said congestion should have been alleviated. 

7. A congestion management method for use by a packet phone adapter in a packet network 
environment, said method comprising the steps of: 

collecting congestion data associated with a packet telephony communication; 
10 determining if said packet telephony communication had a duration that exceeded a 

predefined threshold; and 

reporting said congestion data to a centralized server that performs overload control, 
whereby said centralized server evaluates said congestion data to determine if a path associated with 
said packet telephony communication is congested. 

15 

8. The method of claim 7, further comprising the step of setting a timer that will cause said 
congestion data to automatically expire after a predefined period of time. 

9. The method of claim 8, wherein said timer expires after a period of time within which 
20 said congestion should have been alleviated. 

10. A congestion manager for use in an Internet Protocol-based private branch exchange 
system within a packet network environment, comprising: 

a memory for storing computer readable code; and 
25 a processor operatively coupled to said memory, said processor configured to: 

receive congestion data from at least one device that participated in a packet telephony 
communication; 

determine if said congestion data indicates that a path associated with said packet 
telephony communication is congested; and 
30 set a congestion indicator flag associated with said path if said congestion data indicates 
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that a path associated with said packet telephony communication is congested. 

11. The congestion manager of claim 10, wherein said processor is further configured to 
maintain a timer that will cause said congestion indicator flag to automatically expire after a predefined 
period of time. 

12. The congestion manager of claim 1 1 , wherein said timer expires after a period of time 
within which said congestion should have been alleviated. 
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